The description herein generally relates to 3-D rendering systems, system architectures, and methods. Some of the examples described herein relate to systems, architectures, and methods for asynchronous and concurrent hybridized rendering, such as hybridized ray tracing and rasterization-based rendering.
Graphics Processing Units (GPUs) often provide highly parallelized rasterization-based rendering hardware. A traditional graphics processing unit (GPU) used a fixed pipeline only for rendering polygons with texture maps and gradually evolved to a more flexible pipeline that allows programmable vertex and fragment stages. Even though modern GPUs support more programmability of geometry and pixel processing, a variety of functions within a GPU are implemented in fixed function hardware. Modern GPUs can range in complexity, and may be adapted to be suited for particular uses. When designing a GPU, there is often a trade-off between various factors such as performance, size, power consumption and cost. GPUs are often used in real time rendering tasks, and optimizations for many GPU applications involve determining shortcuts to achieve a desired throughput of frames per second, while maintaining a desired level of subjective video quality. For example, in a video game, realistic modeling of light behavior is rarely an objective; rather, achieving a desired look or rendering effect is often a principal objective.
Traditionally, ray tracing is a technique used for high quality, non-real time graphics rendering tasks, such as production of animated movies, or producing 2-D images that more faithfully model behavior of light in different materials. In ray tracing, control of rendering and pipeline flexibility to achieve a desired result were often more critical issues than maintaining a desired frame rate. Also, some of the kinds of processing tasks needed for ray tracing are not necessarily implementable on hardware that is well-suited for rasterization.
As an example, ray tracing is particularly suited for introducing lighting effects into rendered images. Sources of light may be defined for a scene which cast light onto objects in the scene. Some objects may occlude other objects from light sources resulting in shadows in the scene. Rendering using a ray tracing technique allows the effects of light sources to be rendered accurately since ray tracing can be used to model the behaviour of light in the scene.
Light maps can be built which represent lighting in the scene. For example, a light map is a 2D data structure which stores indications of the luminance and colour of lighting effecting surfaces in the scene, which can be used in a similar manner to a texture in a graphics rendering process, e.g. a light map can be texture mapped onto the surface of objects in a 3D scene. In this sense a light map can be thought of as an “unwrapped” map of the surfaces in the scene capable of being lit. A light map includes values at particular positions, which may be referred to as texels of the light map. To translate from a 3D surface in the scene (e.g. a surface of a primitive) texture coordinates (u,v) associated with the point on the surface can be determined, e.g. by interpolation of texture coordinates for the vertices of the primitive. The u and v values can be used as a coordinate of the light map to determine a lighting for the primitive surface.
Ray tracing rendering techniques are often relatively computationally expensive and memory intensive to implement. For example, determining the values of a light map (which may be referred to as “baking” the light map) is often a computationally expensive process because direct lighting and/or indirect lighting should ideally be taken into account. Determining indirect lighting may require many rays may be processed for each light map texel. This means that the baking of light maps is typically performed as an “offline” process, i.e. before runtime in which images are being rendered. Calculating a light map before runtime means that the light map is usually an estimate of the lighting in the scene that is rendered at runtime, and as such errors can occur. It also means that the lightmap is incapable of responding to changes in the scene such as the moving of objects or changes to the light sources. The processing involved in baking a light map is typically too computationally expensive to be performed in real-time.